Présentation de DevSecOps

Qu’est-ce que le DevSecOps ?

DevSecOps est l’intégration des pratiques de sécurité dans un modèle de livraison de logiciels DevOps. Cette intégration repose sur une culture au sein de laquelle les équipes de développement et opérationnelles disposent des processus et outils leur permettant de partager la responsabilité de la livraison de logiciels sécurisés.

Sans entrer dans le détail, nous pouvons définir le modèle DevSecOps comme l’intégration des objectifs de sécurité aussi tôt que possible dans le cycle du développement logiciel. Si la sécurité est la responsabilité de tous, les équipes DevOps disposent d’une position privilégiée, à l’intersection du développement et des opérations, et peuvent travailler sur la sécurité à la fois de manière verticale et horizontale.

Quelle est la différence entre DevOps et DevSecOps ?

Pour faire simple, la différence entre DevOps et DevSecOps réside dans la culture de la responsabilité partagée. DevOps est un concept débattu et décrit depuis plus de dix ans. Il dispose ainsi de nombreuses définitions. Il s’agit avant tout d’un paradigme organisationnel visant à unir les pratiques de développement et opérationnelles dans une responsabilité partagée.

Comparaison DevOps et DevSecOps

Ce qui était au début un ensemble disparate de pratiques partagées par des équipes d’ingénierie logicielles performantes s’est structuré en une définition moderne de la culture et du processus d’ingénierie : DevOps. Les organisations qui ont choisi de partager la responsabilité du développement et des opérations sont en mesure d’itérer plus facilement et sont donc plus performantes. DevSecOps va plus loin en codifiant les objectifs de sécurité dans les objectifs globaux. À ce titre, il doit être vu comme une extension naturelle de DevOps plutôt que comme une idée ou un concept distinct. Les équipes qui parviennent à appliquer les pratiques DevOps doivent considérer le DevSecOps comme une évolution, et non pas comme une révolution.

Pour beaucoup, l’objectif était de créer un environnement permettant le déploiement du code selon un processus fluide et pérenne afin de générer de la valeur. Ce nouveau modèle s’est accompagné d’outils et de méthodologies qui ont permis d’aller plus vite, mais ont abouti à la formation naissance d’un goulot d’étranglement au niveau des anciennes pratiques de sécurité, dont les boucles de rétroaction plus lentes ont fini par limiter les pratiques DevOps. Par conséquent, les pratiques de sécurité intervenaient souvent après la mise en production ou étaient réalisées par des équipes externes intégrées au processus, ce qui ralentissait donc les choses.

Pour clarifier la différence entre DevOps et DevSecOps, disons que DevSecOps étend la culture de la responsabilité partagée de DevOps aux pratiques de sécurité. Les activités pensées pour identifier et, idéalement, résoudre les problèmes de sécurité, interviennent tôt dans le cycle du développement des applications et non pas après la publication. Pour que cela soit possible, il est nécessaire de permettre aux équipes de développement de réaliser une bonne partie des tâches de sécurité de manière indépendante au cours du cycle du développement logiciel.

Cette approche limite le nombre de vulnérabilités arrivant jusqu’en production et réduit donc le coût associé à la correction des défauts de sécurité. Il en résulte une meilleure évolutivité, ainsi que la naissance d’une culture collaborative rapprochant la sécurité des objectifs DevOps. DevSecOps cherche à intégrer la sécurité dans chaque étape du processus de livraison, dès la définition du cahier des charges, et à établir un plan d’automatisation de la sécurité.

L’importance du DevSecOps

Pourquoi les pratiques DevSecOps sont-elles essentielles ?

Pour la quasi-totalité des entreprises, la transformation digitale est désormais une question de survie. Cette transformation se compose de trois éléments principaux : la multiplication des logiciels, le recours aux technologies cloud et l’adoption des méthodologies DevOps.

La multiplication des logiciels se traduit par une digitalisation du risque de l’entreprise : la dette technique augmente et la sécurité des applications gagne donc en complexité. Il devient par conséquent de plus en plus difficile de sécuriser les ressources digitales.

Le recours au cloud se traduit quant à lui par des technologies plus récentes, qui impliquent des risques différents, une évolution plus rapide et un accès plus large. Le concept même de « périmètre sécurisé » doit ainsi être repensé. Cela signifie également que bon nombre des risques informatiques et d’infrastructure passent dans le cloud, quand d’autres deviennent purement logiciels. Ces risques sont ainsi réduits, mais la gestion des autorisations et des accès devient essentielle.

Enfin, DevOps transforme le développement et la livraison des logiciels en raccourcissant le délai séparant l’écriture du code, la génération de valeur pour le client et la compréhension et l’adaptation au marché. Les équipes de développement accompagnées livrent leurs logiciels en continu, plus rapidement que jamais, en prenant seules et sans intermédiaires les décisions relatives à la technologie et l’implémentation. Les boucles de rétroaction traditionnelles, si lentes qu’elles pèsent sur le processus de développement, ne sont plus tolérées. Aujourd’hui, les équipes donnent la priorité à l’autonomie en exécutant elles-mêmes le code qu’elles écrivent.

Avec l’évolution du reste de leur organisation, les équipes de sécurité sont confrontées à des exigences plus fortes et finissent par devenir elles-mêmes un goulot d’étranglement. Les outils et pratiques de sécurité des applications, pensées pour l’ancien monde, antérieur au cloud et moins frénétique, les transforment en obstacle à la livraison d’applications de qualité. Ces équipes manquent de bras en raison d’une grave pénurie de collaborateurs compétents, se transforment en un goulot d’étranglement et ne parviennent tout simplement plus à suivre. Par conséquent, les équipes de développement livrent des applications non sécurisées, les équipes de sécurité s’effondrent sous la charge de travail, et la sécurité bloque les initiatives, empêchant l’accélération visée par l’entreprise.

Face à ces difficultés, les pratiques ont commencé à changer. C’est ainsi que DevSecOps est né. Une culture DevSecOps intègre la sécurité dans DevOps. Les équipes de développement peuvent ainsi sécuriser leurs projets à leur rythme, et la collaboration entre développeurs et chargés de la sécurité devient plus rapprochée. Elle permet aux équipes de sécurité de se positionner en soutien, en mettant son expertise et ses outils au service de l’autonomie des développeurs, tout en maintenant le niveau de supervision exigé par l’entreprise.

Les 6 avantages du modèle DevSecOps

1. Livraison plus rapide : la vitesse de livraison des logiciels augmente lorsque la sécurité est intégrée au pipeline. Les bugs sont identifiés et corrigés avant le déploiement, ce qui permet aux développeurs de se concentrer sur la livraison des fonctionnalités.

2. Sécurité renforcée : la sécurité est prise en compte dès la phase de conception. Un modèle de responsabilité partagée assure une intégration étroite de la sécurité à la fois lors du développement, du déploiement et de la sécurisation des charges de travail de production.

3. Coûts réduits : l’identification des vulnérabilités et des bugs avant le déploiement permet une réduction exponentielle du risque et des coûts opérationnels.

4. Amélioration de la valeur DevOps : l’intégration des pratiques de sécurité dans le modèle DevOps permet de faire de l’amélioration de la sécurité une responsabilité partagée. Le rapport Snyk/Puppet 2020 DevSecOps Insights l’a constaté au sein des entreprises DevSecOps matures.

5. Amélioration de l’intégration et de la rapidité de la sécurité : le coût et les délais liés à la livraison de logiciels sécurisés diminuent, car il n’est pas nécessaire d’ajouter des contrôles de sécurité a posteriori, après le développement.

6. Contribution à l’amélioration des performances globales de l’entreprise : une plus grande confiance dans la sécurité des logiciels développés et l’adoption de nouvelles technologies permettent de doper la croissance des revenus et d’étendre l’offre.

Adoption du DevSecOps : intégration de la sécurité dans le pipeline de CI/CD

La plupart des organisations DevOps modernes combinent systèmes d’intégration continue et de déploiement/livraison continus dans un pipeline de CI/CD. Le pipeline constitue une base idéale, à partir de laquelle il est possible de procéder à divers tests et validations de sécurité sans intervention humaine.

Adoption de DevSecOps : intégration de la sécurité dans le pipeline de CI/CD

Pour intégrer les objectifs de sécurité tôt dans le développement d’une application, il est nécessaire de s’y intéresser avant même l’écriture de la première ligne de code. Les équipes de sécurité peuvent intégrer et réaliser des modélisations efficaces des menaces dès le travail sur le concept initial du système, de l’application ou de la user story. L’analyse statique, les linter et les moteurs de politiques peuvent être exécutés à chaque intégration de code par un développeur, ce qui garantit de résoudre les problèmes avant qu’ils ne progressent dans le pipeline.

Une analyse de la composition des logiciels peut être exécutée de manière globale pour s’assurer que toutes les dépendances open source sont soumises à des licences compatibles avec votre logiciel et ne comportent aucune vulnérabilité. Avec ce processus, les développeurs se sentent davantage concernés par la sécurité de leurs applications, car ils reçoivent un retour immédiat sur la sécurité relative du code qu’ils ont écrit.

Une fois le code intégré et généré, vous pouvez démarrer les tests d’intégration de sécurité. L’exécution du code dans une sandbox au sein d’un conteneur isolé permet de réaliser des tests automatiques d’éléments comme les appels réseau, la validation des saisies et les autorisations. Ces tests génèrent des retours rapides et permettent donc une itération rapide et un tri sans délai des problèmes repérés, avec à la clé une perturbation très limitée du flux global. Si des appels réseau inattendus ou des saisies non nettoyées sont détectés, le test échoue, et le pipeline génère un retour concret sous la forme de rapports et de notifications envoyés aux équipes concernées.

Une fois que l’artefact de déploiement a passé la première batterie de tests d’intégration, il passe à l’étape suivante. Il est ainsi déployé dans une sandbox plus vaste, une copie limitée de l’environnement de production final. À ce stade, de nouveaux tests d’intégration peuvent être réalisés, mais cette fois-ci avec des objectifs différents.

Il est désormais possible de tester le bon fonctionnement de la journalisation et des contrôles d’accès, par exemple. L’application consigne-t-elle bien les indicateurs de performance et de sécurité nécessaires ? L’accès est-il bien limité aux personnes appropriées ou entièrement bloqué ? Encore une fois, en cas d’échec, des informations sont envoyées aux équipes concernées.

Enfin, l’application arrive en production. Toutefois, le travail DevSecOps ne s’arrête pas pour autant. L’automatisation de l’application des correctifs et de la gestion de la configuration garantit que l’environnement de production utilise toujours les versions les plus récentes et sécurisées des dépendances logicielles. Dans l’idéal, le recours à une infrastructure immuable signifie que l’ensemble de l’environnement est reconstruit de zéro, constamment soumis à la batterie de tests tout au long du pipeline.

L’utilisation d’un pipeline de CI/CD DevSecOps permet d’intégrer les objectifs de sécurité à chaque phase, sans ajouter de processus administratifs et de filtrages lourds, ce qui permet de maintenir le rythme de livraison de valeur métier.

Favoriser une culture DevSecOps

Mais alors, comment une organisation peut-elle passer du DevOps au DevSecOps ? Il ne suffit pas de confier à une équipe DevOps déjà bien occupée une liste de KPI de sécurité. Vous devez mettre en place une culture partagée et collaborative de l’itération rapide.

Si l’intégration des objectifs de sécurité au plus tôt est la cible visée, vous devez néanmoins faire en sorte que le processus soit aussi fluide que possible. Le fardeau de l’intégration des équipes et objectifs de sécurité dans le flux de valeur ne doit pas retomber sur les épaules des développeurs. En effet, toute étape supplémentaire ne fera qu’allonger le délai de livraison de fonctionnalités aux clients. L’équipe de sécurité doit adopter un fonctionnement agile, avec une approche pragmatique consistant à sécuriser sans perturber.

Lors du processus de planification, en particulier vis-à-vis de l’infrastructure, les ingénieurs en sécurité doivent participer aux discussions et refuser les choix inadaptés ou non sécurisés, mais aussi être suffisamment formés pour être en mesure de formuler des alternatives. Trop souvent, les équipes de sécurité débordées se contentent d’un «non » et confient la recherche d’alternatives aux équipes DevOps. Encore une fois, nous en revenons à l’idée de mettre des ressources suffisantes à la disposition des organisations de sécurité.

Lorsque les équipes de sécurité et DevOps collaborent tôt et souvent, les objectifs de sécurité sont étroitement liés à l’infrastructure. Les fonctionnalités et les applications déployées en production résultent alors d’une collaboration complète et efficace entre les équipes de sécurité, de développement et des opérations. Les équipes de sécurité n’auront pas à réclamer des fonctions supplémentaires ou auditer les équipes de développement a posteriori, elles sauront que ces fonctions sont présentes depuis le premier jour.

Si votre organisation a adopté les pratiques DevSecOps, vous savez que vous itérez rapidement et offrez ainsi de nouvelles fonctions améliorées à vos clients, mais que cette expérience s’accompagne aussi d’une sécurité de haut niveau.

Lisez cet article de Snyk sur la marche à suivre pour déployer le DevSecOps en 4 étapes si ce n’est pas déjà fait.